Some software systems include an instrumentation system to, among other things, assist in debugging, audit user actions and monitor performance and/or overall health of the system. For example, some server applications include an instrumentation system for such monitoring. Typically, these systems define two distinct roles that system components participate in when dealing with instrumentation: the generation of instrumentation data, referred to as events in the rest of this document, and the consumption and analysis of the instrumentation events, which may also include the relaying of the instrumentation events from the producer to the consumer. For example, a server application may generate instrumentation events describing the service requests it processes, and may relay this data via the network to a database where a human administrator queries it to review application usage. In such a system, the generation of the instrumentation events, and the transfer and analysis of it may happen under vastly different and variable rates, often due to the processing and space constraints of the relaying and consumption mechanism, and the frequently uncontrollable rate of generation which depends on application usage. Because of this, there is a need for a mechanism that seeks to honor the processing constraints and the desired event delivery demands of the consumer and the transfer channel, while avoiding the loss of real-time generated instrumentation events.